Device Interrupts

Device Interrupts

device interruptinterrupt:devicedevice driverWhen a device needs attention, it requests an interrupt. This forces one CPU to trap to an interrupt handler to service the interrupt. The interrupt handler locates a device driver that can respond to the interrupt. There are two kinds of device drivers:

Multiprocessor-aware device drivers can run on any CPU. The interrupt handler enters the code of the device driver immediately, on the CPU that was interrupted.
Device drivers that are not multiprocessor-aware cannot be executed safely on any CPU. The interrupted CPU in turn interrupts CPU 0, and then returns to the interrupted work. The interrupt handler in CPU 0 calls the old device driver.

Interrupts at the same and lower priority levels are masked off (blocked) in the interrupted CPU while the device driver is running. Other CPUs continue to run, and can even receive interrupts.

The design of multiprocessor-aware device drivers is covered in the IRIX Device Driver Programmer's Guide (see page xxiii). Disk and network drivers are always multiprocessor-aware. However, VME device drivers (other than disk drivers) are not required to be multiprocessor-aware.

VME Interrupts

interrupt:VME busVME bus:interrupt levelsbus,VME. <Italics>See<Default Para Font> VME bus<$nopage>Interrupts from the VME bus are grouped into 7 priority levels. Each device on the bus uses a particular level. Higher numbered levels have superior priority (IRQ7 is superior to IRQ1).

interrupt:sprayingBy default, interrupts are "sprayed" (dynamically distributed, in rotation) to all CPUs in order to equalize the load of handling interrupts. You can control this in two ways:

Designate CPUs that are not to receive sprayed interrupts. You would do this to protect real-time processes in those CPUs from being interrupted by devices not related to real-time work.
Specify that interrupts of a specified VME interrupt level are to be directed to a specified CPU. You would do this either to group all non-real-time interrupts on a designated CPU, or to direct real-time interrupts to a CPU that is dedicated to handling them.

For details on these actions, see "Minimizing Overhead Work" in Chapter 6.

Interrupt Latency

interrupt:latencyWhen interrupts come from the real-time input and output devices, you are concerned about interrupt latency, the amount of time that elapses between the hardware signal and the start of the IRIX kernel's response to it. Interrupt latency has several sources, some of which you can control. (See "Components of Interrupt Response Time" in Chapter 6.)

Interrupt Response Time

device service timedevice driverinterrupt response timeThe time that elapses from the arrival of an interrupt until the system returns to executing user code is interrupt response time. It includes interrupt latency, plus the time spent in the device driver (called device service time), plus the time IRIX needs to switch program contexts, and other factors. When you take full advantage of the features of IRIX and REACT/Pro and configure the system properly, you can guarantee a maximum 200 microsecond interrupt response time. See "Minimizing Interrupt Response Time" in Chapter 6.